Growing DONE—How to Make the Definition of Done Work for Your Team

Effective agile teams get things done. They build software day after day that’s not just “code complete” but really shippable. And when their product owner says, “ship it,” they can get their shippable software into production at the drop of a hat.

The Definition of Done can be a powerful tool to make these things happen…If it’s used right.

Most agile teams I see have one of four relationships with a Definition of Done:

1. They don’t have one
2. They have one but don’t really use it
3. They have one but can never satisfy it
4. They have one, satisfy it for each story, but still have lots to do at the end of a release

I rarely come across teams who use the Definition of Done to good effect day after day, sprint after sprint.

The reason why, I think, is that if a team uses a Definition of Done at all, they try to use a single one before they’re ready. I’ve discovered that most teams really need two definitions of done. For a new agile team, there’s more to do to get software ready for production than can be accomplished a story at a time. Teams that fall into #3 above probably put everything on the Definition of Done. Teams in #4 probably put just those things they could do a story at a time on the Definition of Done and left everything else for later.

The answer is two Definitions of Done. The Story Definition of Done captures what the team can do today to make each story as shippable as possible in each sprint. The Release Definition of Done captures the gap between the Story Definition of Done and what’s actually required to ship. Together these tools provide a way to visualize what done means and to make it happen as early as possible.

Here’s how to build effective Story and Release Definitions of Done…

Building The Two Definitions of Done

1. Brainstorm the List

List all the things required to move a set of features in your product to production. Engage release management, operations, help desk, and other stakeholders at this point—it’s easier to build what they need into the software than to bolt it on at the end. This list typically includes things like:

• user documentation
• operations documentation
• monitoring and logging
• performance testing
• regression tested in a clean QA environment

Now, list anything required to deliver software at a consistently fast pace from iteration to iteration. For example:

• automated unit tests covering 80% of code
• automated story tests covering 90% of acceptance criteria
• adherence to coding standards
• code reviewed by another developer
• all production code developed by a pair

Finally, list non-functional requirements such as:

• all pages load in under a second
• all pages can support 300 simultaneous user sessions

Merge these lists into one, changing the language where necessary so that each bullet reads as a continuation of the sentence beginning: “In order for a set of features to be released to production…”

2. Challenge the List

For each item on the list, ask “why?” Keep asking “why?” until it’s clear that the item is the simplest, cheapest, most repeatable way to achieve some desired goal in the release. If it’s not, change it.

This is where you challenge the existing rules around releases. Maybe your release readiness guidelines today require a complete installation guide. Could you replace that with an automated installation script?

3. Build Release Readiness In

Now you have a list of the minimal set of things a group of features must have to be released—your Release Definition of Done. Bolting those things onto an otherwise complete set of features could impose a fixed cost of weeks to the end of any release. One of our goals in agile is to allow the product owner to be able to say at any point, “This is enough, I want to start making money off of this software now—ship it.” An expensive release gets in the way.

Look at each item on the list and ask, “Could we satisfy this as we build each story instead of all at once at the end of a release?” Yes? Then move it to your Story Definition of Done. No? Could you do part of it or do something that would reduce the time at the end? Yes? Then put that on your Story Definition of Done. No? Then leave it on the Release Definition of Done.

Very few items can’t be satisfied a story at a time. The most common ones I see are performance testing in a production-like environment shared with other products and beta testing with a set of real users. But you can get a head start on even these. Maybe your test environment isn’t exactly like production, but can you make the performance constraints similar enough to at least profile for likely performance issues? Maybe you can’t beta test on a large scale, but could you get a small set of users to volunteer to use stories as they’re built and provide early feedback to make the beta test shorter and more predictable? Think hard about anything you’re tempted to leave on the Release Definition of Done.

4. Use Your Definitions of Done

You now have two definitions of done, one for every story you build and one for a collection of stories you want to release. The Story Definition of Done will inform your acceptance criteria for every story. If page load time matters, a story isn’t done until all the related pages load fast enough. Test for this. Automate these tests and run them on every build if you can.

You won’t satisfy the items on your Release Definition of Done until the end of a release. But this doesn’t mean you can forget about them until then. Keep the Release Definition of Done visible, and look for ways to test early for release readiness.

5. Grow Your Story Definition of Done

The Definitions of Done are a starting place, a statement of what your team can accomplish today. Over time, your Release Definition of Done should get smaller and your Story Definition of Done should grow. If you have 3 weeks of manual regression testing at the end of each release, come up with a plan to grow automated regression tests as you build new stories. Maybe you can reduce those 3 weeks of testing to one. If you have a tech writer spend a month writing documentation at the end of a release today, find ways to integrate her into the team to grow the documentation as you grow the software. Maybe you can reduce that month of writing to 3 days of editing and polishing.

The Bottom Line

Use two definitions of done. In every retrospective, look for ways to grow your Story Definition of Done so you can consistently build and release software quickly. If you get to a point where you can throw away the Release Definition of Done, congratulations! But don’t start there.